home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9806 / 000024_owner-linux-arm…r.rutgers.edu _Tue Jun 2 11:50:17 1998.msg < prev    next >
Internet Message Format  |  1998-06-30  |  9KB
  1. Return-Path: <owner-linux-arm-outgoing@vger.rutgers.edu>
  2. Received: from virtual.bbc.co.uk (virtual.bbc.co.uk [132.185.132.199])
  3.     by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id LAA01180
  4.     for <willy@odie.barnet.ac.uk>; Tue, 2 Jun 1998 11:50:16 +0100
  5. Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
  6.     by virtual.bbc.co.uk (8.8.5/8.8.5) with ESMTP id LAA15216
  7.     for <willy@bofh.ai>; Tue, 2 Jun 1998 11:50:33 +0100 (BST)
  8. Received: from vger.rutgers.edu ([128.6.190.2]:14176 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <2571-22190>; Tue, 2 Jun 1998 13:50:22 +0300
  9. Received: by vger.rutgers.edu id <970801-25900>; Tue, 2 Jun 1998 05:37:25 -0400
  10. Received: from alpha.Xerox.COM ([13.1.64.93]:4681 "HELO alpha.xerox.com" ident: "firewall-user") by vger.rutgers.edu with SMTP id <970796-25900>; Tue, 2 Jun 1998 05:37:20 -0400
  11. Received: from toaster.parc.xerox.com ([13.1.102.43]) by alpha.xerox.com with SMTP id <56167(1)>; Tue, 2 Jun 1998 03:49:05 PDT
  12. Received: from toaster.parc.xerox.com (localhost [127.0.0.1]) by toaster.parc.xerox.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA15375 for <linux-arm@vger.rutgers.edu>; Tue, 2 Jun 1998 03:49:02 -0700
  13. Message-Id: <199806021049.DAA15375@toaster.parc.xerox.com>
  14. Reply-To: stewart@parc.xerox.com
  15. To: linux-arm@vger.rutgers.edu
  16. Subject: EBSA-285 adventures
  17. Date:     Tue, 2 Jun 1998 03:49:01 PDT
  18. From: Paul Stewart <stewart@parc.xerox.com>
  19. X-Orcpt: rfc822;linux-arm@vger.rutgers.edu
  20. Sender: owner-linux-arm@vger.rutgers.edu
  21. Precedence: bulk
  22. X-Loop: majordomo@vger.rutgers.edu
  23. Status: RO
  24.  
  25.   First of all, I'd like to thank Russell King, Dave Gilbert, Philip
  26. Blundell, Linus, the Itsy team and all the other Linux and ARM-Linux
  27. developers for their artifacts allowing me to get this far with only
  28. web searches and an FTP here or there.  I continue to marvel at the
  29. incredible dedication and attention to detail that has cultivated
  30. this work.
  31.  
  32.   That said, I've got a quasi-success report, for those who may not
  33. have been able to piece together the entire procedure for cross-
  34. compiling for the EBSA-285, and then a slightly off- topic question
  35. that I hope others who work with this sort of hardware may be able
  36. to shed light on.
  37.  
  38.   My goal is to get an EBSA-285 up and running linux.  I had on hand
  39. the Digital EBSA-285 eval board, the 5-volt passive backplane, a
  40. 22140A-based ethernet card, and for development purposes a i586 
  41. linux box.  To get any real support, I quickly realized from 
  42. summaries of diffs and reading the config code for 2.0.33 that a 
  43. 2.1.xx(x) kernel would be critical, since it seemed that the real 
  44. watershed for EBSA-285 support came in the experimental branch of 
  45. the kernel.  My first attempt at compiling such a kernel came with
  46. picking up the latest of everything: Linux 2.1.103, the latest 
  47. snapshot of binutils (2.9.1.0.4) and egcs snapshot 19980531, all 
  48. of relatively recent vintage.
  49.  
  50.   This approach, of course was met with failure, first because
  51. the lack of ELF support in egcs.  The 2.1 kernels require ELF support
  52. in many crucial places.  After a little hunting I found diffs to 
  53. gcc 2.7.2.2 on Russell's exceedingly helpful ftp site,
  54. ftp://ftp.arm.uk.linux.org/pub/armlinux/tools/.  It was a little hard
  55. to find, since the patches that were highlighted in the webpages and
  56. READMEs were for the ARM/a.out variety, which is probably more useful
  57. to the folks building on 2.0 systems, and moreover it appears that 
  58. even on the 2.1 kernels, the a.out format is still the defacto 
  59. application binary format.  
  60.  
  61.   My attempt at using gcc-2.7.2.2 with binutils 2.9.1.0.4 looked
  62. promising... all the way up until the final link stage where I
  63. got nasty looking messages about overflows in relocation.  I took
  64. this as a sign that I should have just taken the "binutils-2.8-elf"
  65. diff also on Russell's site and used that.  There was an ever-so-
  66. slight version skew between the two.  gcc-2.7.2.2 seemed to have 
  67. a problem reminiscent of a warning on Russell's Tool page: while
  68. compiling in the 3Com directory, I got failure messages from the
  69. assembler complaining that "Processor does not support halfwords 
  70. or signed bytes" from gas/config/tc-arm.c.
  71.  
  72.   I considered two things to be wrong with this: Firstly, the 
  73. compiler failed to suppress StrongARM instructions.  I was 
  74. prepared to forgive this, especially since the EBSA-285 is a 
  75. StrongARM-based processor.  It was still a bug, but not one I was 
  76. prepared to tackle just then.  The second issue was that since
  77. I was on a StrongARM, I'd actually like to pass that code on to
  78. the assembler and have it take advantage of those instructions.
  79. Towards this purpose, I modified gcc to support a "-msa110",
  80. which worked just like the (perhaps broken) "-m6" argument,
  81. except it passed the "-msa110" down to the binutils-2.8 
  82. assembler, which did accept this flag.  I think modified
  83. arch/arm/Makefile to have a check for CONFIG_CPU_SA110 in the
  84. non-"CONFIG_BINUTILS_NEW" branch of CONFIG_CPU_32.
  85.  
  86.   The last of the patches that I applied should have been made
  87. at the very beginning: I'd assumed that by 2.1.103, that the
  88. kernel had been made mostly ARM-friendly, and a patch of the
  89. magnitude of the earlier ones for 2.0.33 and 2.1.99 which I
  90. had picked up before.  To my surprise there were 72k lines of 
  91. modifications, covering many of the issues I'd found in my 
  92. first passes at a compile and addressing quite a few more 
  93. issues I'd expected to run into on the horizon, like a VGA
  94. console.  A great big "attaboy" goes out to Russell and whoever
  95. else made it possible for me not to think about what exactly
  96. KSTK_ESP() was and what to set it to for ARM architectures.
  97.  
  98.   The only configuration option that gave me trouble was "CONFIG_FB",
  99. which when enabled, started a compile in arch/arm/drivers/char1.  
  100. I'm not sure what the semantic significance of "CONFIG_FB" is, but it 
  101. would appear that I do not need it, since the arch/arm/drivers/char
  102. path seems to have what I want and compiles cleanly with CONFIG_FB
  103. turned off.
  104.  
  105.   So, to summarize, here's how I got a vmunix for my EBSA-285:
  106.  
  107.   * Acquire gcc-2.7.2.2, binutils-2.8, from ftp://prep.ai.mit.edu,
  108.     and linux-2.1.103 from ftp.linux.org
  109.  
  110.   * Acquire and apply patches to all of these from the ones
  111.     provided on ftp://ftp.arm.uk.linux.org/pub/armlinux/
  112.  
  113.   * (Optionally?) modify this patched gcc to invoke the StrongARM
  114.     assembly personality in GAS.
  115.  
  116.   * Configure and compile the development tools.  I guess 
  117.     arm-unknown-linuxelf will work in most places.  I started 
  118.     using arm-unknown-elf, and had to modify a few config scripts 
  119.     to maintain that nomenclature.  Don't forget to rename the
  120.     binutils-generated filenames in your $prefix/bin/ dir as 
  121.     Dave Gilbert's instructive post to this list pointed out 
  122.     (speaking of which, where would be the best place to keep
  123.     this post archived?  There are web pages that reference this
  124.     post) -- you'll need all the tools to have the same root name
  125.     when you supply the CROSS_COMPILE line to the Linux Makefile.
  126.     
  127.  
  128.   * Configure and compile linux.  All done (we hope)
  129.  
  130.  
  131.   So what's my problem?  Actually getting this kernel into the
  132. EBSA-285.  Angelboot would appear to be the right answer, available
  133. both from Causality (http://www.causality.com/) and in modified 
  134. form as a part of the Linux-on-brutus distribution at
  135. http://www.research.digital.com/wrl/people/kerr/linux-brutus.html.
  136. The problem I'm having is that the EBSA seems entirely unresponsive
  137. in the angel debug protocol.  Configuring it without an ethernet 
  138. card plugged in and attached only via serial, it prints out the
  139. version banner on bootup, and is completely silent and does not
  140. respond to angelboot's packets.  When an 21140A card is plugged
  141. in, it emits no traffic whatsoever, although from the status lights
  142. on the card, it's apparent that the EBSA has initialized the PHY.
  143.  
  144.   Has anyone seen this behavior before?  Running the self-test flash
  145. image returns successful results (including echoing back characters
  146. sent to the serial port), so if this is a hardware problem, it is
  147. a strange one.  Writing the "angel2" ROM image into the flash via
  148. the PCI bus was successful, but this image exhibits the same 
  149. behavior, after outputting a slightly different version banner.
  150.  
  151.   Anyway, I'd like to thank all the folks who have gotten me here
  152. so far, by the mere virtue of publishing their artifacts.  I hope
  153. that my relatively large "ObArmLinux" has bought me at least a
  154. little credit for a arm-hardware question.
  155.  
  156. --
  157. Paul
  158.  
  159.  
  160.  
  161. unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu